Operating systems are traditionally installed on, and closely tied to, a particular computing platform. The term computing platform may refer to both physical hardware such as server blades, network components and mass storage devices, as well as virtual computing platforms provided by hypervisors. Operating system mobility may refer to the ability to boot and run an operating system on more than one computing platform, for example, physical and/or virtual computing platforms. Current systems may only allow for operating system mobility between computing platforms that are of the same type. For example, operating system mobility may be available from one server blade to another server blade of the same type or from one hypervisor to another hypervisor of the same type.
Modern operating systems may include a bootstrapping mechanism to load the integral parts of the operating system and its various hardware drivers into the main memory of a computing platform during a boot process. Typically, the installation procedure may place the necessary operating system files on an attached boot disk and may set the configuration of the operating system installation in such a way that the critical drivers necessary to boot are in the correct location within the boot disk and loaded in the correct order. Parts of the bootstrap mechanism may be dependent upon the hardware initialization and startup procedures such as a Basic Input/Output System (BIOS) or an Extensible Firmware Interface (EFI).
Computing, network and storage resources are increasingly becoming virtualized. This virtualization may introduce an additional abstraction layer between hardware and software, which allows for a looser coupling between computing, network and storage resources. In this manner, software may be more easily migrated to spare hardware before the original hardware is taken offline for maintenance. Examples for this approach can be found in many hypervisor applications. Virtualized network switches and blade technology also may allow for similar functionality without the use of hypervisors. In these examples, systems may need to be stopped and restarted during the migration, whereas hypervisors can perform this task without downtime.
Furthermore, with the advent of Storage Area Networks (SAN), Network Attached Storage (NAS) and Server Virtualization, the lines between locally attached storage, physical storage and virtual storage are blurred. Utilizing such network boot systems, a storage device with a pre-installed operating system can quickly be detached and attached to compatible, but different, hardware. The storage device may also serve as a bootable startup disk from which the hardware initialization may read the operating system loader and continue the boot process.
For example, an operating system installed in a Logical Unit Number (LUN) served by a storage system could be simultaneously made available via Fibre Channel (FC), internet Small Computer System Interface (iSCSI) target or even as a flat file on a Network File System (NFS) or a Common Internet File System (CIFS). Similarly, the hardware attached to the LUN may be from different manufactures or even different virtualized machines.
As discussed above, the current technology for migrating an operating system between computing platforms has limitations and typically only allows for operating system mobility between computing platforms that are of the same type. For example, source and target computing platforms must be of the same system type for the migration to be successful. For addressing this problem, cluster takeover and hardware redundancy paradigms have been proposed, which may be relatively expensive to implement. Therefore, a need exists for operating system mobility for computing platforms of different types, where the source and destination types can be any combination of physical or virtual computing platforms.